Micron Document
`:top
Das `!Dependency Inversion Principle`! (`!DIP`!, `F33f`_`[englisch`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Englische_Sprache]`_`f für `!Abhängigkeits-Umkehr-Prinzip`!) ist ein Prinzip beim `F33f`_`[objektorientierten Entwurf`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Objektorientiertes_Design]`_`f von `F33f`_`[Software`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Software]`_`f. Es beschäftigt sich mit der Abhängigkeit von `F33f`_`[Modulen`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Modul_(Software)]`_`f.

Im Allgemeinen wird das DIP beschrieben durch:

`*Module höherer Ebenen sollten nicht von Modulen niedrigerer Ebenen abhängen. Beide sollten von Abstraktionen abhängen.`*
`*Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.`*

>>Contents

• `F0af`_`[Problemstellung und Lösung`#problemstellung-und-l-sung]`_`f
• `F0af`_`[Beispiel`#beispiel]`_`f
• `F0af`_`[Siehe auch`#siehe-auch]`_`f
• `F0af`_`[Literatur`#literatur]`_`f

-─

>>Problemstellung und Lösung

`F33f`_`[Objektorientierte Entwürfe`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Objektorientiertes_Design]`_`f werden in `F33f`_`[Module`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Modul_(Software)]`_`f strukturiert, die unterschiedliche Verantwortlichkeiten umsetzen. Eine gängige Praxis ist das Anordnen der Module in Ebenen. Je niedriger die Ebene eines Moduls, desto spezieller sind die Vorgänge, die es definiert. In Modulen niedrigerer Ebenen werden Abläufe definiert, welche von allgemeineren Abläufen in höheren Ebenen benutzt werden.

Falls diese Anordnung falsch umgesetzt wird, also Module höherer Ebenen von Modulen niedrigerer Ebenen abhängen, entsteht ein Problem. Änderungen in Modulen niedrigerer Ebenen führen unweigerlich zu Änderungen in Modulen höherer Ebenen. Dies widerspricht aber einerseits dem eigentlichen Ansatz der Hierarchie, andererseits führt es zu zyklischen Abhängigkeiten. Dadurch kommt es zu einer erhöhten `F33f`_`[Kopplung`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Kopplung_(Softwareentwicklung)]`_`f der Module, welche Änderungen in Architektur und Design unnötig verkomplizieren.

Der Lösungsansatz ist die Invertierung der Abhängigkeit. Das Modul der höheren Ebene definiert die Schnittstelle, mit der es arbeitet. Module niedrigerer Ebene realisieren die Schnittstelle.

>>Beispiel

Wir betrachten ein einfaches Schalter-Lampe-Modell. Das Drücken des Schalters soll die Lampe an- oder ausschalten.

Eine einfache Implementierung in `F33f`_`[Java`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Java_(Programmiersprache)]`_`f:

`B100`F9d9public class Lampe {`f`b
`B100`F9d9 private boolean leuchtet;`f`b
`B100`F9d9`f`b
`B100`F9d9 public void anschalten() {`f`b
`B100`F9d9 leuchtet = true;`f`b
`B100`F9d9 }`f`b
`B100`F9d9`f`b
`B100`F9d9 public void ausschalten() {`f`b
`B100`F9d9 leuchtet = false;`f`b
`B100`F9d9 }`f`b
`B100`F9d9}`f`b
`B100`F9d9`f`b
`B100`F9d9public class Schalter {`f`b
`B100`F9d9 private Lampe lampe;`f`b
`B100`F9d9 private boolean gedrueckt;`f`b
`B100`F9d9`f`b
`B100`F9d9 public Schalter(Lampe lampe) {`f`b
`B100`F9d9 this.lampe = lampe;`f`b
`B100`F9d9 }`f`b
`B100`F9d9`f`b
`B100`F9d9 public void drueckeSchalter() {`f`b
`B100`F9d9 gedrueckt = !gedrueckt;`f`b
`B100`F9d9 if(gedrueckt) {`f`b
`B100`F9d9 lampe.anschalten();`f`b
`B100`F9d9 } else {`f`b
`B100`F9d9 lampe.ausschalten();`f`b
`B100`F9d9 }`f`b
`B100`F9d9 }`f`b
`B100`F9d9}`f`b

Schalter steuert den Ablauf des Verhaltens und benutzt dazu Lampe. Demnach sollte es einem Modul höherer Ebene angehören. Jedoch verletzt das beschriebene Modell das DIP, da Schalter abhängig von Lampe ist. Wird entschieden, dass die Methoden von Lampe umbenannt werden, muss auch Schalter geändert werden.

Das grundlegende Problem ist, dass Schalter direkt mit Lampe arbeitet, welches zu einem niedrigeren Modul gehört. Schalter sollte selbst definieren, wie das Objekt aussehen sollte, mit dem es arbeitet.

Die Lösung in Java:

`B100`F9d9public interface Geraet{`f`b
`B100`F9d9 public void anschalten();`f`b
`B100`F9d9 public void ausschalten();`f`b
`B100`F9d9}`f`b
`B100`F9d9`f`b
`B100`F9d9public class Lampe implements Geraet{`f`b
`B100`F9d9 private boolean leuchtet = false;`f`b
`B100`F9d9`f`b
`B100`F9d9 public void anschalten() {`f`b
`B100`F9d9 leuchtet = true;`f`b
`B100`F9d9 }`f`b
`B100`F9d9`f`b
`B100`F9d9 public void ausschalten() {`f`b
`B100`F9d9 leuchtet = false;`f`b
`B100`F9d9 }`f`b
`B100`F9d9}`f`b
`B100`F9d9`f`b
`B100`F9d9public class Schalter {`f`b
`B100`F9d9 private Geraet lampe;`f`b
`B100`F9d9 private boolean gedrueckt;`f`b
`B100`F9d9`f`b
`B100`F9d9 public Schalter(Geraet lampe) {`f`b
`B100`F9d9 this.lampe= lampe;`f`b
`B100`F9d9 }`f`b
`B100`F9d9`f`b
`B100`F9d9 public void drueckeSchalter() {`f`b
`B100`F9d9 gedrueckt = !gedrueckt;`f`b
`B100`F9d9 if(gedrueckt) {`f`b
`B100`F9d9 this.lampe.anschalten();`f`b
`B100`F9d9 } else {`f`b
`B100`F9d9 this.lampe.ausschalten();`f`b
`B100`F9d9 }`f`b
`B100`F9d9 }`f`b
`B100`F9d9}`f`b

>>Siehe auch

• `F33f`_`[Service Provider Interface`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Service_Provider_Interface]`_`f
• `F33f`_`[Plug-in`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Plug-in]`_`f
• `F33f`_`[Inversion of Control`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Inversion_of_Control]`_`f

>>Literatur

• Robert C. Martin: The Dependency Inversion Principle. Mai 1996 (PDF (`F33f`_`[Memento`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Webarchivierung]`_`f vom 14. Juli 2011 im `*`F33f`_`[Internet Archive`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Internet_Archive]`_`f`*)).

`c`F0af`_`[↑ Back to top`#top]`_`f`a